Блог про блоги от Дмитрия Донченко

Внимание Google Recaptcha v3 + Contact Form 7

Сегодня случилась ситуация, которая заставила вспомнить что есть блог и в него нужно писать.

90% а может и больше сайтов, пользуются контактной формой и так повелось, что как правило за работу этой контактной формы отвечает плагин Contact Form 7 плагину этому уже не первый год и он отлично зарекомендовал себя как плагин для простой контактной формы или для сложных форм заказов с условиями и множеством полей.

В декабре 2018 в плагин добавили совместимость Google Recaptcha v3 и полностью отказались от v2 (там где нужно нажимать «Я не Робот» и отгадывать картинки).

Это очень здорово и удобно для пользователя, потому что ничего нигде не нужно вводить, решать примеры, искать картинки и тратить время на разгадывание капчи, но есть одно но.

Если посетитель заполняет форму с подозрительного адреса (допустим общественный Wi-Fi) который гугл посчитает «Плохим источником», то при заполнении формы пользователь не получит уведомление о том, что что-то не так с капчей, да и что с ней может быть если ее нет. Он будет просто получать уведомление о том, что при отправке сообщения возникла ошибка, попробуйте еще раз. И даже после того как он несколько раз нажмет отправить, ситуация не изменится, в итоге кто-то потеряет драгоценный лид не важно заказ это, обращение или вопрос.

На данный момент как справиться с этой ситуацией не меняя версию капчи я не нашел. Чтобы возобновить работу контактной формы, пришлось доставить еще один плагин, который говорит Contact Form 7 использовать Google Recaptcha v2, сгенерировать ключи для второй версии капчи и ввести их заново в настройках Contact Form 7.

Если у вас установлен плагин Contact Form 7 и используется невидимая капча Google Recaptcha v3 рекомендую проверить работу контактной формы с разных компьютеров / телефонов, возможно не все обращения через контактную форму доходят до адресата.

Продолжить чтение...

Как отключить Gutenberg

Недавно я организовывал небольшой опрос в Twitter, по поводу того нравится ли новый редактор блоггерам и ответы были неоднозначны, кому-то нравится, кому-то не очень.

Лично я на данном этапе наших взаимоотношений с ним его просто ненавижу. Возможно это звучит громко, но он этого заслуживает.

Когда вы зашли в админку и видите объявление о том что: «Грядет новый издательский опыт» не повторяйте ошибок многих и не нажимайте «Установить Guttenberg».

 

Вместо этого лучше нажать «Установить Classic Editor».

Почему именно так?

1. Оказывается при включенном Guttenberg редакторе, плагины которые делаю кирилическими ссылки, перестают их обрабатывать и вы получаете ссылку вида: mysite.com/название-моей-записи/ на момент написания поста cyr3lat cyr-to-lat не обрабатывают ссылки новых записей.
2. Если у вас тема со встроенным блочным редактором и она не обновляется (ну например потому что вы не оплатили обновления) с вероятностью 90% при включении нового редактора с сайтом у вас будут проблемы в виде пустых страниц как минимум.
3. Возможно я сильно привык к классическому редактору, но в  новом Guttenberg нужно сделать слишком много телодвижений чтобы просто написать пост.

Возможно этот список будет обновляться по мере нахождения новых «невозможностей» нового редактора.

Если я вас не убедил и вы все еще хотите попробовать, возможно вас убедит рейтинг этого редактора в каталоге плагинов WordPress.

 

Если все еще хотите попробовать, сделайте перед этим резервную копию файлов сайта и базы данных, либо делайте это на тестовой копии своего сайта.

Название поста «Как отключить Guttenberg», а об этом еще не слова, исправляю ситуацию.

Код который необходимо добавить в functions.php вашей темы, для отключения редактора Guttenberg.

// Disable Gutenberg

if (version_compare($GLOBALS['wp_version'], '5.0-beta', '>')) {
	
	// WP > 5 beta
	add_filter('use_block_editor_for_post_type', '__return_false', 10);
	
} else {
	
	// WP < 5 beta
	add_filter('gutenberg_can_edit_post_type', '__return_false', 10);
	
}

После этого редактор будет переключен на классический.

Расскажите в комментариях ваш опыт работы с Guttenberg и будете ли вы им пользоваться в дальнейшем.

Продолжить чтение...

Массовое удаление пунктов меню в WordPress.

Этот пост не несет особой смысловой нагрузки, он просто хвалебная ода еще одному полезному плагину который я долго искал.

Иногда приходится удалять сразу много пунктов меню в WordPress, причин может быть несколько, например вы установили тему, залили в нее демо контент и вместе с ним меню, оно красивое, вам нравится, но некоторые пункты (а их бывает много) лишние, чтобы не тратить кучу времени открывая каждый пункт чтобы нажать «Удалить», мы можете удалить их все сразу используя вот этот плагин: WP Edit Menu есть еще один похожий плагин в каталоге плагинов WordPress, но он давно не обновлялся и не отмечен как совместимый с актуальными версиями WordPress.

Работает плагин очень просто, установили, заходим в раздел «Внешний Вид» — «Меню«, на каждом пункте меню появится поле для отметки, на тех полях которые хотим удалить, ставим галочки, и в самом низу нажимаем на кнопку «Remove Items«.

Плагин настолько хорош, что заставил меня написать отдельный пост о нем и поставить ссылочку на страничку плагина. Буду рад если он вам пригодится.

Продолжить чтение...

Частичный редирект для robots.txt для Nginx

В последнее время стало популярным переводить сайты на защищенный протокол https. Это повышает безопасность работы с сайтом, это якобы повышает лояльность поисковиков к сайту и вообще классно и модно.

Статей по переводу WordPress на HTTPS в сети огромное множество, поэтому не буду на этом останавливаться.

Намного интереснее задачи и проблемы которые могут возникнуть при переводе сайта на работу с SSL сертификатом.

Одна из них, это то, что Яндекс во время переезда хочет чтобы файл robots.txt был доступен ему и по протоколу http и по протоколу https.

В инструкциях для Apache пишут что можно сделать вот так:

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:X-HTTPS} !1
RewriteCond %{REQUEST_URI} !robots.txt
RewriteRule ^(.*)$ https://SiteName.ru/$1 [R=301,L]

А вот кусочек конфига который работает на Nginx. Возможно не самое изящное решение, но оно работает:

set $do_redirect  1;
if ($scheme ~* ^https$) {
    set $do_redirect 0;
}
if ($request_uri ~* ^/robots\.txt$) {
    set $do_redirect 0;
}
if ($do_redirect = 1) {
   return 301 https://$server_name$request_uri;
}

Некоторые вообще считают что это не критичная проблема и Яндекс сам разберется где ему искать новый robots.txt, но если клиент хочет, значит нужно сделать :-)

А как бы вы решили данную задачу?

Продолжить чтение...